Wiring these two jars into generateConfigReference publishes the generated metadata straight into the Application Properties reference, and grails-views-markup has no curated overlay. Generating the reference from this branch:

• 33 of 187 rows now have an empty Description and an empty Default: all 24 grails.views.markup.*, plus the 9 newly inferred grails.views.json.* entries (baseTemplateClass, cache, enableReloading, extension, packageImports, packageName, staticImports, templatePath, useAbsoluteLinks). Every pre-existing row in that file has a description, so all 33 blanks are new.
• The markup rows land inside the existing "Views & GSP" section, interleaved with fully documented grails.views.gsp.* rows, so they read as holes in an otherwise complete table.

Every one of these is settable, so every one needs documenting. Can we add grails-views-markup/src/main/resources/META-INF/additional-spring-configuration-metadata.json with a group description plus a description and default for each of the 24, and descriptions for the 9 new JSON Views entries, before these jars feed the reference?

SEMANTIC_ANALYSIS runs before @Delegate composes (DelegateASTTransformation is CANONICALIZATION), so delegate-generated setters are invisible to collectSetterProperties. CORS is exactly that case: running :grails-web-url-mappings:generateConfigurationMetadata on this branch, the generated half contributes only grails.cors.enabled and grails.cors.mappings. allowedOrigins, allowedMethods, allowedHeaders, exposedHeaders, maxAge and allowCredentials — all bindable through the @Delegate GrailsDefaultCorsConfiguration and Spring's CorsConfiguration setters — survive only because the new overlay lists them by hand.

That is a reasonable limitation to accept, but today it fails silently: add a delegated property and the metadata simply will not have it, with nothing in the build to say so. Can we state the limitation in the class documentation, and ideally have the transform warn (or the task fail) when a @ConfigurationProperties class carries a @Delegate field, so whoever adds one is told to extend the overlay?

isNested treats every type outside java.*/groovy.* as a nested configuration group, and collectSetterProperties walks superclasses and interfaces without applying that filter at all — it only stops at Object. The two hardcoded names on line 174 are what keeps that from exploding today: JsonViewConfiguration and MarkupViewConfiguration implement the GenericViewConfiguration trait, which extends GrailsApplicationAware, so without the setGrailsApplication exclusion the transform would recurse into GrailsApplication.

Boot's own processor keys nesting off inner classes and @NestedConfigurationProperty rather than a package-name heuristic, and the ASM path in this PR is already narrower — it nests only into types found in the same module's output (models[property.rawType()]). Could the Groovy path use the same restriction, and honour @NestedConfigurationProperty? As written, the next config class with a setter taking a framework or third-party bean type silently emits a nested group tree, and the remedy will be another name added to that blocklist.

Applying buildsrc.publish (with the matching publish-root-config.gradle entry) puts this module on Maven Central, and because grails-bom/base adds every published subproject as a constraint it lands in grails-bom too. It is also the only new module that deliberately skips gradle/docs-config.gradle, so it ships as a published artifact with no API docs. It is compileOnly on the five framework modules, so it never reaches their POMs, and nothing outside this build can use it without the unpublished build-logic plugin.

It also registers a global transform via META-INF/services/org.codehaus.groovy.transform.ASTTransformation. Once published, anyone who ends up with it on a compile classpath silently gets __grailsConfigurationMetadata injected into their own @ConfigurationProperties classes, and a hard compile error if they happen to declare a field with that name. Is there a consumer that needs the artifact? If not, dropping the publish/sbom/vulnerability-scan plugins and the publishedProjects entry keeps it internal to the build.

Separately, compileOnly 'org.springframework.boot:spring-boot' on line 39 looks unused — the transform matches ConfigurationProperties and ConstructorBinding by name string and imports nothing from Spring.

ClassModel does not implement equals, so previous != model is identity comparison and is always true for two distinct instances. This reduces to "fail on any duplicate class name across the input directories", which is not what the guard reads as. Either give ClassModel value equality (or compare prefix/payload) so a genuinely identical duplicate is tolerated as intended, or drop the second condition so the code says what it does.

indexByName enforces name uniqueness per category. That is right for properties, but Boot's format allows repeated group names distinguished by sourceType/sourceMethod, and generate() emits one group per @ConfigurationProperties class (line 128) plus one per nested holder. Two config classes sharing a prefix in the same module, or a nested prefix reachable from two classes, would fail the build with Conflicting generated groups metadata for '...' on metadata that is legal. Worth keying groups on name + sourceType, or merging instead of rejecting.

With CORS moved out, this file still carries 10 groups and 24 properties for prefixes spanning URL mappings, content negotiation, static resources and scaffolding. Not a blocker for this PR, but is the intent to keep relocating those to the modules that own them as they gain @ConfigurationProperties classes? Worth capturing in #15469 so this file does not stay the central fallback by default.

Two feature methods for a 277-line transform leaves most of the logic that decides what gets published unexercised. The TestKit spec covers the Java/ASM half thoroughly, but the Groovy half is only tested through one happy-path class, so the branches below can change behaviour without any test noticing:

• @Delegate field exclusion, and the setGrailsApplication/setMetaClass exclusions.
• collectSetterProperties walking superclasses and interfaces — a config class extending a base class and implementing a trait is the shape both view configurations actually have, and it is the source of most generated properties.
• constructorBoundProperties selection: @ConstructorBinding on one of several constructors, the "no no-arg constructor plus exactly one candidate" rule, and private/synthetic constructors being ignored.
• A non-constant prefix expression, which makes addPayload bail out entirely and silently hands the class to the bytecode bean-scan path instead — worth pinning, since the two paths do not infer the same set.
• typeName/genericTypeName for arrays, wildcards (? extends / ? super) and type variables.
• The hand-rolled toJson/escapeJson. A constant default containing a quote, backslash, newline or control character is written into a class-file string constant and parsed back by JsonSlurper in the Gradle task; if the escaping is ever wrong the failure surfaces as a JSON parse error during someone else's module build.
• An interface annotated @ConfigurationProperties (skipped by !node.interface), and a prefix-less @ConfigurationProperties.

Each is a few lines of parseClass in this spec, and they are what makes the mechanism safe to change later.